home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / mhs / mhs_40.txt < prev    next >
Text File  |  1993-04-10  |  26KB  |  527 lines

  1. Introduction
  2.  
  3. Novell's NetWare MHS product family provides a messaging
  4. infrastructure service.  With the introduction of NetWare 4.0, MHS
  5. is able to provide a new level of service, particularly with
  6. respect to directory support.
  7.  
  8. Because messaging is by nature a fully distributed service that is
  9. used on a network-wide basis, the concept of a directory is very
  10. important.  NetWare Global MHS is Novell's NLM-based messaging
  11. product that includes messaging-specific directory support designed
  12. to (1) service environments without NetWare 4.0, (2) integrate
  13. NetWare 3.X messaging environments with NetWare 4.0, and (3)
  14. propagate message routing information.  This approach allows
  15. NetWare Global MHS to provide the complete messaging solution
  16. required by customers and MHS application developers.
  17. Directory integration of NetWare 3.X and NetWare 4.0 is made
  18. possible because the NetWare Global MHS directory is structurally
  19. identical to NetWare 4.0 directory service (NDS), permitting a
  20. single, hierarchical name space to be visible to both NetWare 4.0
  21. users and NetWare 3.X users.
  22.  
  23. NetWare MHS  
  24.  
  25. NetWare MHS is a store-and-forward messaging technology that
  26. provides messaging and directory services to any desktop that has
  27. file access to a NetWare server (e.g. DOS, Windows, Macintosh,
  28. Unix, and OS/2), and to disconnected laptops.
  29. MHS is typically used in conjunction with messaging applications
  30. such as e-mail, calendaring, and network fax.  Commercial third
  31. party products include DaVinci's eMail and Coordinator, Beyond's
  32. BeyondMail, Reach's MailMAN and WorkMAN, Powercore's WinMail,
  33. Infinite's ExpressIT!, Notework's Notework, Futurus' Team,
  34. MicroSystems Software's CaLANdar, Campbell Services' OnTime,
  35. Castelle's FaxPress, Lantec's XPost, Optus' FACSys, CE Software's
  36. QuickMail, Transend's CompletE-Mail, and many others (see the
  37. NetWare Messaging Solutions Guide).  In addition, MHS comes with a
  38. starter e-mail package, FirstMail, to enable the user to get
  39. started with messaging.
  40.  
  41. Submitting a message to MHS is as easy as creating a text file with
  42. appropriate headers and giving MHS access to the new file.  This
  43. simplicity makes it easy for third parties to develop applications
  44. and for system integrators and corporate developers to utilize the
  45. messaging system.  For example, an e-mail message may look like
  46. this:  
  47.  
  48. smf-71
  49. To: Bob Smith @ marketing . acme
  50. From: Tim Johnson @ engineering . acme
  51. Subject: Q1 Results?
  52.  
  53. Are the quarterly results in yet?
  54.  
  55.  
  56. Once a message has been submitted, MHS takes the message and
  57. determines how to route it through the messaging system.  MHS
  58. implements various messaging protocols, including the standard MHS
  59. protocols as well as other industry standards such as SMTP, SNADS,
  60. and X.400.
  61.  
  62. After sending a message through the messaging system, MHS delivers
  63. the message into a file that the recipient's application may
  64. access.
  65.  
  66. In addition to the messaging service, MHS provides a directory
  67. system for use by MHS and its applications.  An application gains
  68. access to directory information by opening a shared file on the
  69. NetWare server that contains information about which users are on
  70. the messaging system.  E-mail applications typically use this
  71. information to provide point-and-click lists to the users.
  72. The naming scheme for MHS is hierarchical.  For example,
  73.  
  74.  
  75. Bob Smith's MHS name is formed from this tree: BobSmith @ marketing
  76. . acme.
  77.  
  78. The nodes in the naming tree that aren't leaf nodes are called
  79. workgroups.  Thus Acme is a workgroup that contains two other
  80. workgroups, marketing.acme, and engineering.acme.
  81.  
  82. This hierarchical naming scheme allows a single unique global name
  83. for all MHS messaging users to ensure that no two MHS messaging
  84. users in the world have the same MHS name.  In addition, this
  85. naming scheme is structurally identical to NetWare 4.0 directory
  86. services (NDS).
  87.  
  88. Applications can also gain access to the directory information. 
  89. They typically use this information to provide point-and-click
  90. lists to the users.  MHS provides this information in the form of
  91. an extract file.  The extract file contains sorted records in a
  92. fixed length format.  Each record contains information about a user
  93. of the messaging system, such as mail address, phone number, title,
  94. department, etc.
  95.  
  96. The sharing of directory information between servers is
  97. accomplished through a subscription mechanism.  This mechanism is
  98. another characteristic of the NetWare Global MHS directory that
  99. logically relates to NDS functionality.  By subscribing to a
  100. "foreign" workgroup, the names of all users in this workgroup are
  101. appended to the current workgroup and appear to be locally
  102. accessible.  
  103.  
  104. NetWare Global MHS 
  105.  
  106. The NetWare Global MHS product provides scalable, fully integrated
  107. MHS services to NetWare 3.X users.  A version of NetWare Global MHS
  108. which is fully NetWare 4.0 "aware" will be released in Q3 '93. 
  109. Implemented as a set of NetWare Loadable Modules (NLMs) for NetWare
  110. 3.X and NetWare 4.0, NetWare Global MHS enables the network
  111. operating system to support a complete messaging infrastructure. 
  112. This approach allows messaging services to be easily installed, and
  113. capitalizes on existing NetWare investments. NetWare Global MHS
  114. provides built-in directory support, routing,
  115. workgroup-to-workgroup connectivity, and offers optional protocol
  116. modules for messaging interoperability with users on SMTP, SNADS,
  117. and X.400 systems. 
  118.  
  119. In order to understand how Global MHS and NetWare 4.0 work
  120. together, it is important to understand the directory
  121. synchronization mechanisms implemented by Global MHS in the NetWare
  122. 3.X environment.
  123.  
  124. Users and their associated mailboxes can be added to a server in a
  125. 3.X environment through the administrative utility in Global MHS. 
  126. That server becomes the "owner" of that user object, and it
  127. commands the right to modify or delete the object.  The fact that
  128. this object exists is propagated by MHS to other MHS systems by
  129. creating MHS directory synchronization messages.  In addition to
  130. user information, distribution lists and workgroup information is
  131. also propagated the same way.  To minimize synchronization traffic,
  132. only changes in the directory are propagated immediately.  MHS will
  133. also periodically (e.g. monthly) synchronize  the entire directory
  134. to ensure that all servers have the same directory information
  135. (this is useful to guard against undelivered directory
  136. synchronization messages that may have resulted from servers being
  137. down for a long period of time, or a loss of a communications
  138. link). Global MHS also uses directory synchronization messages to
  139. synchronize routing information, including which servers are
  140. connected to each other and by what protocol. 
  141.  
  142. Global MHS uses the user information in the directory for routing
  143. purposes.  Routing in Global MHS is  a two-step process.  The first
  144. step is to look up the recipient's name to determine on which
  145. server the mailbox is.  The second step is to examine the
  146. connectivity of the network to determine the best path to that
  147. server.  Messages are then routed accordingly.  
  148.  
  149. NetWare 4.0
  150.  
  151. NetWare 4.0 implements a variety of new services and functionality. 
  152. The feature that is particularly relevant to MHS is NetWare
  153. Directory Services (NDS).  NDS implements a distributed directory
  154. database that takes over the role performed by the bindery in
  155. previous releases of NetWare.
  156.  
  157. NDS is very similar in model to the X.500 international standard
  158. and to the NetWare Global MHS directory.  Names in the directory
  159. are hierarchical:
  160.  
  161. This is very similar to the MHS naming scheme, with the exception
  162. that NDS permits nodes in the directory tree to have a type
  163. associated with them such as organization, or common name.  In the
  164. example above, "org" is short for "organization", "ou" is short for
  165. "organizational unit," and "cn" is short for "common name."  Note
  166. that NDS specifies that use of these types is optional, and even
  167. when used, typing is not normally visible to the user or to the
  168. application.
  169.  
  170. API access to the NDS directory is very broad, providing read and
  171. write access to a large number of objects, allowing for yellow-page
  172. search operations, comparison of attributes, modification to the
  173. schema of the directory and partition management. In addition to
  174. information about users, the directory can contain information
  175. about many other types of objectsAprinters, devices, queues, file
  176. volumes, and more.  Since the schema is extensible, other types of
  177. information can be added as well.
  178.  
  179. In order to facilitate management of the directory, NDS divides the
  180. tree into logical divisions or partitions.  The partitions may not
  181. overlap, and each node in the tree falls into a partition.
  182.  
  183.  
  184. In the above example, the tree is divided into two partitions. 
  185. Information about each partition is kept in a file on a server. 
  186. The administrator determines where the "master copy" of the
  187. partition data resides, and where replicas of each partition (if
  188. any) are to be kept.  Making replicas of partitions increases the
  189. reliability of the directory and can increase the performance of
  190. the directory.  If a query to the directory is made and the
  191. currently attached server does not have the information locally, it
  192. will refer the requester to a server that does have the
  193. information.  The effect of replicated partitions is very similar
  194. to the Global MHS subscription mechanism.
  195.  
  196. MHS in a NetWare 4.0 Environment
  197.  
  198. Single Naming Scheme
  199.  
  200. Using NetWare Global MHS in a NetWare 4.0 environment provides the
  201. administrator with a single unified view of the naming scheme.  A
  202. user is given a name such as Joe Jones@marketing.acme.  This single
  203. name is used as a unique network identity for the user regardless
  204. of the usageAnetwork login, file access control lists, point and
  205. click lists in email applications, and other applications,
  206. administrative programs and utilities. 
  207.  
  208. Single Point of Administration
  209.  
  210. Using MHS in the NetWare 4.0 environment brings a new level of
  211. integration between NetWare and MHS.  The standard administration
  212. utilities that come with NetWare can be used to administer mail
  213. accounts.  One of the attributes of the user object in NDS is used
  214. to identify where the mailbox for that user resides.  When this
  215. attribute is set, NDS notifies MHS, which takes care of the
  216. administrative details such as setting up the user's account A
  217. creating the necessary file directories, and, if appropriate,
  218. updating the MHS routing tables, and notifying other MHS systems
  219. that don't have access to NDS (more on this later). 
  220.  
  221. In addition to the NetWare utilities for managing users,
  222. workgroups, and distribution lists, MHS provides administrative
  223. utilities for managing other aspects of the messaging system such
  224. as configuring the messaging connectivity, management of the
  225. messaging queues, viewing of messaging statistics and network
  226. utilization, etc.
  227.  
  228. Remote Administration
  229.  
  230. NetWare 4.0 implements a network-wide view of services.  This
  231. allows the entire network to be administered from the vantage point
  232. of a single-user interface.  Global MHS capitalizes on this feature
  233. to provide remote administration of the MHS messaging system. 
  234. Using the standard NetWare 4.0 utilities NETADMIN  (DOS version),
  235. or NWADMIN (Windows version), an administrator can add users with
  236. mailbox accounts on servers throughout the 4.0 network.  In
  237. contrast, using Global MHS in the NetWare 3.X environment requires
  238. the user to use, for example, RCONSOLE  to connect to each
  239. messaging server to which a mailbox is to be added.
  240.  
  241. Directory Synchronization
  242.  
  243. Global MHS leverages the powerful directory services provided with
  244. NetWare 4.0.  When a user is added to the NetWare 4.0 network, NDS
  245. replicates that information as needed throughout the network,
  246. relieving Global MHS from that responsibility.  In contrast, Global
  247. MHS in the NetWare 3.X environment, by necessity, propagates
  248. information about new users added to the system to other Global MHS
  249. systems using directory synchronization messages.
  250.  
  251. On each system with Global MHS, NDS invokes MHS to perform the
  252. necessary account administration and updates the MHS routing
  253. database and extract file.
  254.  
  255. API Access
  256.  
  257. With MHS running on NetWare 4.0, all of the same interfaces that
  258. are provided throughout the MHS product family are fully supported. 
  259. MHS provides SMF v70 and SMF v71 APIs, and maintains all of the
  260. administrative interfaces common to the product lineAthe same "snd"
  261. directory for submitting messages, the same extract file for
  262. accessing the messaging directory, the same configuration files for
  263. setting up auto-forwarding, etc.  An application written to support
  264. Global MHS in the NetWare 3.X environment will continue to operate
  265. in the 4.0 environment without any modification, and all messaging
  266. relevant directory information is available using the file-based
  267. extract mechanism. The administrator controls the contents of the
  268. extract file by setting up local NDS replicas of the pieces of the
  269. directory tree he desires to be accessible to his messaging users.
  270. Future versions of SMF will also incorporate additional information
  271. relevant to messaging services in order to satisfy ongoing
  272. developer requirements and the evolution of NDS.
  273.  
  274. In addition to the usual access to the extract file, applications
  275. can use the NDS APIs to get access to the directory information. 
  276. These APIs provide powerful interfaces for directory services,
  277. including directory searches, modification to the directory schema,
  278. and management of the directory partitions. Third-party developers
  279. wishing to take advantage of these features will create
  280. applications fine-tuned for the NetWare 4.0 environment, whereas
  281. developers desiring to have a single product that will run across
  282. the entire NetWare messaging product line will continue to use the
  283. messaging directory interfaces.
  284.  
  285. Theory of Operation
  286.  
  287. The following diagram shows the components involved in the
  288. messaging and directory system.
  289.  
  290. The system is administered from a workstation running standard
  291. NetWare utilities.  When a new user is added to the network, NDS
  292. notifies MHS.  Should the administrator wish to assign a mailbox
  293. location for the user, the mailbox must be located on a server
  294. where partition information containing the user, master or replica,
  295. is stored.  When the mailbox is assigned, MHS will create the
  296. actual mailbox and update the routing and extract files.  MHS will
  297. also take care of updating other workgroup routing and extract
  298. files through its normal synchronization process.
  299.  
  300. Global MHS also maintains synchronization of routing information. 
  301. Routing information is administered through Global MHS
  302. administration utilities and is propagated through its own
  303. directory synchronization messages, not through the NDS directory.
  304.  
  305. The routing process in MHS takes place in the usual Global MHS
  306. fashion. For recipients in the local MHS routing database, the
  307. final destination server is determined from the routing database,
  308. and the connectivity is examined to determine the most efficient
  309. route to that server.  For recipients in the local MHS domain, the
  310. message is sent to the workgroup hub for further routing.  MHS
  311. consults the configured information about foreign domains for
  312. messages destined for external domains.
  313.  
  314. Global MHS in a Mixed NetWare 3.X and NetWare 4.0 Environment
  315.  
  316. Administrative Model
  317.  
  318. Global MHS fully supports environments of mixed NetWare 3.X and
  319. NetWare 4.0 systems, each running MHS.  This is the most powerful
  320. aspect of using MHS with NetWare 4.0.
  321.  
  322. The directories of Global MHS on NetWare 3.X and the NetWare 4.0
  323. systems are unified, providing a single view of the naming
  324. hierarchy.  All Global MHS users on 3.X systems also appear in the
  325. directory on NetWare 4.0, and all NetWare 4.0 names in the local
  326. Global MHS domain appear in the Global MHS directories on the 3.X
  327. system.  A pick list of all the available users in the directory is
  328. offered to an e-mail user on the 3.X system, regardless of whether
  329. the recipient resides on a 3.X or 4.0 system. The same is true for
  330. users on the 4.0 systemApick-lists of all the available recipients
  331. are available, regardless of where that recipient resides.
  332.  
  333. On the 3.X systems, Global MHS is administered as usual.  Each of
  334. the MHS servers on 4.0 systems looks exactly like the MHS systems
  335. running on the NetWare 3.X systems. There is no additional
  336. configuration or management needed on the 3.X systems to
  337. accommodate the mixed model.
  338.  
  339. On the 4.0 systems, Global MHS is administered with the usual
  340. network-centric administration model pioneered in NetWare 4.0. 
  341. Lastly, in a mixed environment, one of the NetWare 4.0 servers
  342. running Global MHS must be designated as the directory
  343. synchronization hub for the 3.X Global MHS directory and the
  344. NetWare 4.0 directory.
  345.  
  346. Theory of Operation
  347.  
  348. A combination of the Global MHS directory synchronization
  349. facilities and the NetWare 4.0 Directory Services makes the high
  350. level of integration between 3.X and 4.0 systems possible.
  351.  
  352. The 3.X systems send all  information on their local users to all
  353. other systems, both 3.X and 4.0, through Global MHS directory
  354. synchronization messages.  The 4.0 systems send all information
  355. about their local users to all 3.X systems through Global MHS
  356. directory synchronization messages.  The 4.0 systems share
  357. directory information with each other through 4.0 NDS.  In
  358. addition, one of the 4.0 systems is designated to be the directory
  359. synchronization hub that adds information about the 3.X Global MHS
  360. names into the 4.0 system.  As in the homogeneous 4.0 environment,
  361. the Global MHS routing database and extract file contain all the
  362. 4.0 messaging users that are contained in any local replica or
  363. master copy of an NDS partition.  This information is combined with
  364. the users information in the 3.X Global MHS environment.
  365.  
  366. Installation and Upgrade Features
  367.  
  368. MHS provides a number of installation and upgrade options to
  369. facilitate the smooth installation and migration of network
  370. operating system and messaging services.
  371.  
  372. When MHS is installed on a NetWare 4.0 system, the administrator
  373. has the option of giving mailboxes to a set of NDS users.  This
  374. eliminates the tedium of having to identify where the mailbox
  375. resides for each individual NetWare 4.0 user.
  376.  
  377. More importantly, the procedure for upgrading from a NetWare 3.X
  378. system that is running Global MHS to a NetWare 4.0 system with
  379. Global MHS offers the option of building the NetWare 4.0 directory
  380. from the existing hierarchical Global MHS directory.  This will
  381. minimize the administrative effort and eliminate errors. 
  382.  
  383. Summary
  384.  
  385. NetWare Global MHS provides a messaging infrastructure service for
  386. NetWare 3.X users, NetWare 4.0 users and, most importantly, for
  387. users of mixed networks.  It provides an integrated, unified
  388. administrative environment as well as a uniform messaging
  389. application platform.  This is primarily enabled by the
  390. complementary directory services feature included in both the
  391. NetWare Global MHS and the NetWare 4.0 products.
  392.  
  393. Questions and Answers
  394.  
  395. Q.  Is it possible to have directory conflicts between Global MHS
  396. and NDS?
  397.  
  398. A.   Since there is a single unified directory, the only possible
  399. conflict is of the same nature as might occur within NDS alone. It
  400. is theoretically possible that two administrators could
  401. accidentally add the same name into the directory, for example,
  402. when two Bob Smiths start work in an organization at the same time
  403. but at different locations. If the two records are created in
  404. NetWare 4.0, NetWare will resolve the       conflicts based on the time
  405. stamps of the operations.  Global MHS in the NetWare 3.X
  406. environment deals with conflicts by sending an e-mail message to
  407. the system administrator asking that he manually rename one of the
  408. users.
  409.  
  410. Q.  How is NDS object typing supported by Global MHS?
  411.  
  412. A.   The typing of objects in the directory is not visible through
  413. the Global MHS administrative utilities, APIs, and MHS-based
  414. applications.  The typing information is not needed for messaging.
  415.  
  416. Q.  How do the administrative paradigms for Global MHS and NetWare
  417. 4.0 compare?
  418.  
  419. A.   NetWare 4.0 and Global MHS running on 4.0 have a common
  420. paradigm since Global MHS administration in the NetWare 4.0
  421. environment is integrated into the NetWare operating system.  The
  422. NetWare 4.0 directory browsing and maintenance utilities are used
  423. to administer a single identity for each user and distribution
  424. list.  Additional messaging-specific utilities are provided to
  425. administer messaging routing information, manage messaging queues,
  426. view messaging statistics, logging, accounting information, and
  427. other messaging specific functions. 
  428.  
  429. Q.  When should an administrator use NETADMIN versus NetWare Global
  430. MHS  administrative tools?
  431.  
  432. A.   The NetWare 4.0 utilities should be used to create and
  433. administer users and distribution lists.  The NetWare Global MHS
  434. administrative tools must be used for messaging-specific
  435. information. 
  436.  
  437. Q.  When should MHS developers use the NetWare 4.0 NDS APIs?
  438.  
  439. A.   It is expected that MHS developers will use the standard SMF
  440. directory interfaces for access to directory information so that
  441. applications will run uniformly in a mixed NetWare 3.X/4.0
  442. environment.  The 4.0 NDS APIs would be used to access
  443. non-messaging related objects such as network device information,
  444. manipulation of the directory access control lists, management, and
  445. to create NetWare 4.0 specific applications.  
  446.  
  447. Q.  What is the relationship between Global MHS "subscriptions" and
  448. NDS  "replicated partitions?"
  449.  
  450. A.   Global MHS running in the NetWare 3.X environment incorporates
  451. the notion of subscription to control the information that is
  452. replicated to a given server.  The administrator subscribes to the
  453. workgroups he wants to show up in an MHS application's "point and
  454. click" lists.  Similarly, portions of the NDS directory tree
  455. (partitions) may be replicated in a controlled manner across
  456. NetWare 4.0 systems. The administrator requests a local copy of a
  457. partition to be replicated for the purpose of redundancy, efficient
  458. access, and in the case of Global MHS, to provide the
  459. point-and-click list to the messaging applications.
  460.  
  461. Q.  Where is the mailbox located when you create a user using
  462. NETADMIN and its network wide view?
  463.  
  464. A.   In NetWare 4.0. a user is created as a "network" user.   One
  465. of the attributes of a user indicates where the mailbox is located.
  466.  
  467. Q.  How are multiple addresses (users may have an MHS, X.400, or
  468. SMTP address) for each user handled?
  469.  
  470. A.   The MHS address is the user's only NetWare identity.  However,
  471. for messaging purposes, a given user may have additional mail
  472. addresses viewed from a non-NetWare messaging system.  For example,
  473. Bob may have a NetWare name of Bob@marketing. acme.  Users of MHS
  474. systems would address messages to this name.  Bob could also have
  475. an SMTP identity of Bob@acme.com.  Users on systems using SMTP
  476. could address Bob using this SMTP name.  All messages transparently
  477. arrive in Bob's mailbox.  Similarly, a user who has a mailbox in a
  478. non-MHS account can be given a NetWare identity.  Sally on a Unix
  479. machine may have an SMTP address of Sally@acme.com, but be given a
  480. NetWare identity of Sally@engineering.acme.  Users on an MHS system
  481. can then send messages to Sally by simply supplying her MHS name. 
  482. This allows MHS users to send messages without having to know
  483. whether the recipient's mailbox is in NetWare, Unix, PROFS, etc. 
  484.  
  485. Q.  How does the upgrade from NetWare v3.11 to NetWare 4.0 work and
  486. what is the process?
  487.  
  488. A.   NetWare 4.0 is installed on top of v3.11.  During the
  489. installation, the administrator is given the option to incorporate
  490. the 3.11 bindery into the NetWare 4.0 directory, placing all the
  491. bindery users into a single directory container.  The administrator
  492. will typically choose this option if he has      applications that
  493. depend on the bindery information for proper operation.  Once the
  494. NetWare operating system is up, Global MHS is upgraded with a
  495. release supporting NetWare 4.0 (available in Q3 '93).  The upgrade
  496. process allows the administrator to create NDS accounts using the
  497. hierarchical name that MHS uses when running in the 3.11
  498. environment.  If the administrator has already created user objects
  499. for bindery emulation, MHS creates alias objects that point from
  500. the hierarchical name to the flat bindery emulation name.
  501.  
  502. Q.  What additional benefits does NetWare 4.0 provide to NetWare
  503. Global MHS?
  504.  
  505. A.   In addition to directory and administrative advantages of
  506. running MHS on NetWare 4.0, MHS takes advantage of enhancements
  507. included in NetWare 4.0 such as memory protection, improvements in
  508. network security, data storage and wide area connectivity.  These
  509. enhancements are provided to MHS through its NLM design.
  510.  
  511. Q.  How will interoperability with X.500 be provided?
  512.  
  513. A.   NetWare 4.0 and NetWare Global MHS directories were built with
  514. X.500 in mind.  The hierarchical directories of NetWare map
  515. directly to the hierarchical name space of X.500.  
  516.  
  517. References
  518.  
  519. NetWare Global MHS Administration
  520. SMF v71 Programmer's Reference
  521. NetWare Directory Services Technical Reference
  522. NetWare 4.0 Directory Services Schema Specification
  523. NetWare 4.0 NLM Library Reference
  524. NetWare 4.0 Supervising the NetWork
  525. NetWare 4.0 Utilities Reference
  526.  
  527.